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References: (a) MSC FA40, ’’Latest in Luminary for Apollo 14," dated 24 July 1970 

received 29 July 1970. R.C6VSU.V- 

(b) Revision 31 of AGO Program Zerlina, dated 16 July 1970, received p ^,y£ 

24 July 1970. ' f 


Reference (a) indicates that MSC plans to incorporate the landing analog 
display routine of reference (b) into the Iif program for the manned Apollo 14 
flight. A review of the coding in reference (b) reveals that the following . 

penalties will have to be paid for this MSC decision (when evaluated against the 
performance of the Luminary 173 program): 

1) Luminary 173 (and the Apollo 13 program) had anomaly L-1B-04 fixed, while 
reference (b) does not. Hence if RR error counters should be disabled, then no 
automatic enabling of them is done (a check of bit 2 of channel 12 is needed). 

Although the anomaly report is not available, reference to Luminary memo #121 
indicates that one way for error counter enable to be reset is "when the RR is 
cycled on and off." 

2) Luminary 173 computed information ; for R1 of N60 (forward velocity) regardless 
of the position of the switch on the spacecraft panel controlling display of data 

on the meters. This change, "authorized" by ACB L-ll (it impacted Section 2 and. 
Section 4 GSOPs), is not in reference (b). Consequently, the warning note on 
page 1-7 and 1-49 of the Apollo 14 Flight Crew G&N Dictionary (15 June 1970) that 
proper R1 data "requires MODE SEL - PGNS" for N60 must be retained, whereas its 
deletion was possible if Luminary I73 had been used. 

3) Luminary 173 allowed the maximum display on the crosspointers (at least 

as fed to the error counters) be about 200 fps, in accordance with the information 
on the required range given on page 5*3-118 of the Section 5 Rev. 8 Approved by 
NASA GSOP. Reference (b), however, contains a constant which seems to limit the 
maximum display to only about half this number (the quantity MAXVEL, line 0140 
on page 43, has a value of 00233g which seems to be about 99*32 X 0.3048 x 0.01 x 2“*, 
where first term is fps, 2nd converts to meters, 3rd to centi-seconds, and fourth 
is scale factor). The program comments indicate a scale factor of "B6", which has 
not been successfully supported by the computations on pages 884-5, which seem to 
make use of a quantity scaled B5 instead. 

4) Although Luminary 173 made use of single precision computations, it provided 
them with a consistent sign. Page 884 of the listing, however, computes forward 
velocity information as: 


FORVTEMP = M32 VHZ, - M22 VHY 


M22 VHY+1 


It appears that the last term has the wrong sign, thus raising the question, in 
view of presumably miccennful tests, of whothor it needs to bo included at all. I' 
omission would save a small amount of execution time. 

5) An apparently influencing factor in reference (a) was that the program 
"begin displaying analog data at TIG - 30 seconds" (item (d) on page 1). Since 
Average-G state vector initialization is for TIG - 29*9 seconds, however, the 
first display (setting of a flagbit) would not be expected to be initiated until 
some time after TIG - 27*9 seconds, not "TIG - 30" as specified by MSC. 
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Given on the following pages is some information on the equations in reference (b) 
in the event this material may have some relationship to what is put in the manned 
ApoMo u program. . f |« jQ g J\P « f, Wfe™ 



r t comments on C'.^'itibility of Luminary 163 Pro w _.1 

o f If 1® with MSC-approved PCRs 287 and 1038 

References: (a) Revision 163 of AGO Program Luminary, dated 29 April 1970, 
received 18 May 1970. 

(b) PCR 287, "Removal of 526 Alarm in P22 and P20>". dated 25 
September 1969. 

(c) PCR 1038, "Keep 526 Alarm in P20 (PCR 287)," dated 27 April 1970. 

A review of reference (a) has revealed several incompatibilities between the 
performance of the program and that authorized by MSC via references (b) and 
(c). These include: 

1. Addition of a lockout on P25 (Preferred Tracking Attitude Program) 
for ranges in excess of about 566 rani (see anomaly LNY k&) • If such a 
range is encountered, a non-display 526 alarm may be generated (depending on 
the "left-over" status of a flagword bit), and manual selection of N54 
could reveal present range. When range.gets below 400 nmi, an attempt 
will be made to start through the P20 program (creating, if radar not in 
Auto, a priority 514g alarm, for example). No mention of P25 was located 
in references (b) or (c). 

2. Addition of a check before generation of the Vl6 N54 display in 
P22 that will.cause "GOTOPOOH" to be entered (via V56 logic) if range rate 
is determined to be positive on first pass through- the computations. No 
mention of such a check was located in references (b) or (c). 

3. Incorporation of a "memory" bit (bit 10 of FIAGWRDO), also used by 
R26, that is not set for entrances to the logic that can occur outside of 
initial selection of P20/P22. In particular, it is not set for a PRO 
response (which might be done quite late compared to first lock-on) to the 
N80 display in R24, nor is it set for entrances to the logic from 
the "LPS20.1" routine, which is used by R6l and R65 (among others).. 

As a result, depending on the status of the "memory bit" an indication to 
the crew of what is happening may or may not be provided. 

Item 1 above is due to the deletion of a check on RNDVZFIG in "IPS20.1" 
that formerly avoided rescaling from B29 to B20 if the bit was zero. As mentioned, 
"LPS20.1" is used by R6l and R65 (and P25 uses R65, after first setting RNDVZFIG = 0) 
Items 2 and 3 should be self-evident from examination of the coding. 










